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TECHNICAL 



The 

RICIS 

Concept 


The University of Houston-Clear Lake established the Research Institute for 
Computing and Information systems in 1986 to encourage NASA Johnson Space 
Center and local industry to actively support research in the computing and 
information sciences. As part of this endeavor, UH-Clear Lake proposed a 
partnership with JSC to jointly define and manage an integrated program of research 
in advanced data processing technology needed for JSC’s main missions, including 
administrative, engineering and science responsibilities. JSC agre ed and entered into 
a three-year cooperative agreement with UH-Clear Lake beginning in May, 1986, to 
jointly plan and execute such research through RICIS. Additionally, under 
Cooperative Agreement NCC 9-16, computing and educational facilities are shared 
by the two Institutions to conduct the research. — 

The mission of RICIS is to conduct, coordinate and disseminate research on 
computing and information systems among researchers, sponsors and users from 
UH-Clear Lake, NASA/JSC, and other research organizati ons. Within UH-Clear 
Lake, the mission is being implemented through interdisciplinary involvement of 
faculty and students from each of the four schools: Business, Education, Human 
Sciences and Humanities, and Natural and Applied Sciences. 

Other research organizations are involved via the “gateway” concept. UH-Clear 
Lake establishes relationships with other universities and research organizations, 
having common research interests, to provide additional sources of expertise to 
conduct needed research. 

A major role of RICIS is to find the best match of sponsors, researchers and 
research objectives to advance knowledge in the computing and information 
sciences. Working jointly with NASA/JSC, RICIS advises on research needs, 
recommends principals for conducting the research, provides technical and 
administrative support to coordinate the research, and integrates technical results 
into the cooperative goals of UH-Clear Lake and NASA/JSC. 
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1. INTRODUCTION 

1.1 Identification of Volume 

This is the Component Acquisition Plan Volume of the Software Management Plan for the 
AdaNet Dynamic Software Inventory (DSI) Management System Prototype. 

1.2 Scope of Volume 

A component acquisition plan contains the information needed to evaluate, select, and 
acquire software and hardware components necessary for successful completion of the 
AdaNet Dynamic Software Inventory (DSI) Management System Prototype. This plan will 
evolve and be applicable to all phases of the DSI prototype development 

1.3 Purpose and Objectives of Volume 

The purpose of this plan is to provide information on what software and hardware 
resources are currently available for development of the DSI prototype and the procedures 
to evaluate, select, and acquire other software and hardware resources which may be 
necessary. 

It is not the intent of this document to specify what software and hardware resources are to 
be used. 

1.4 Volume Status and Schedule 

Version 2 supercedes version 1 and is to be delivered to the Software Engineering Research 
Center (SERC) at the University of Houston Clear Lake by February 15, 1989. 

The preliminary Version 1.0 of this document is due at the University of Houston Clear 
Lake on 3 February 1989. Revisions of this document will include more thorough 
procurement procedures. 

1.5 Volume Organization and Roll-Out 

This volume is rolled-out of the Software Management Plan. 

Sections 1 and 2 of this volume identify it, describe its purpose, and cite other related 
documents. Section 3 provides resources, budgets, schedules, and organization related to 
component acquisition activities. Section 4 is intended to provide a purpose and 
description of a software or hardware component which is to be acquired. Since this is a 
plan for acquisition of all components, this section is not applicable. 

Section 5 describes the procurement activities and events conducted by the acquirer and 
identify who will be responsible, where the activity will be performed, and when the 
activities will occur for each planned procurement. Acquisition requirements are in section 
6 which describes the specific requirements and standards to be followed during 
component acquisition.Section 7 is a detailed discussion of the activities which will take 
place during component acquisition. 

Section 8 contains a list of abbreviations and acronyms, and section 9 a glossary. Section 
10 is available for notes and section 1 1 is the appendix. 


1 


2.0 RELATED DOCUMENTATION 

2.1 Parent Documents 

The following is the parent of this volume: 

1) Software Management Plan of the AdaNet Prototype System, February 1989, 
Software Engineering Research Center (SERC) at the University of Houston Clear 
Lake. 

2.2 Applicable Documents 

The following documents are referenced herein and are directly applicable to this volume: 

1) Clear Lake Conceptual and Implementation Models for Life-Cycle Support 
Environments, Dr. Charles W. McKay, Software Engineering Research Center 
(SERC) at the University of Houston Clear Lake, 1988. 


Management Plan Documentation Standard and Data Item Descriptions Volume of 
the Information System Life-Cycle and Documentations Standards, Release 4.2C, 
8/5/88. Washington: NASA Office of Safety, Reliability, Maintainability, and 
Quality Assurance. 

2.3 Information Documents 


None. 



3.0 RESOURCES, BUDGETS, SCHEDULES, AND ORGANIZATION 

The information in this section is only for the activities directly related to component 
acquisition. 

3.1 Business Practices Definition and Revision Process 

3.1.1 Definition of Activities 

GHG Corp. is to be responsible for obtaining information on the specification, pricing, and 
availability of components identified as needed for the DSI prototype development. An 
initial evaluation of the information will be presented to all members of the DSI prototype 
team by GHG Corp. After final component evaluation and selection is made, GHG Corp. 
will work with the appropriate organizations to see that the component is made available as 
quickly as possible. 

In addition to the above activities, GHG Corp. will maintain a constant search of the market 
place for software and hardware components which may be applicable to the DSI prototype 
development. GHG will inform the appropriate members of the DSI prototype team of any 
components that may be beneficial to the work of the team. 

3.1.2 Method and Approach 
TBD 

3.1.3 Reporting, Monitoring, Revision 

GHG will provide UHCL with the trade studies of components that 

3. 1.3.1 Component Acquisition Reports 

For each component that any member of the DSI prototype team requests GHG to obtain 
information, a report will be produced by GHG which contains a summary of all candidate 
components, an initial evaluation of the candidates, and a suggested selection. A rationale 
for the selection will be given which includes the methods used in the market survey to 
identify candidate components, the methods and criteria used in the evaluation, and the 
determining factors which prompted the selection. Guidelines will be given for the DSI 
team members who will be responsible for the final evaluation and selection. 

After final evaluations and selection has been made, a report that details the evaluation and 
selection will be produced by GHG. The report shall include all of the requirements placed 
on the acquisition, the standards used, the methodologies employed, and an associated 
rationale for each. 

3. 1.3.2 Acquisition Request Acknowledgement 

When a request is received for GHG to help in the acquisition of a needed component, the 
request will be acknowledged by phone within 1 working day. With 3 working days, a 
written acknowledgement will be made which will include any information on candidates 
which have already been identified, an initial assessment of the availability of a component 
to meet the need, and an estimate for the time it will take to conduct a more through market 
survey and complete an initial evaluation and selection. 


3.1.3.3 Market Survey Reports 


GHG will maintain a repository of information on all products and components which are 
identified during routine market surveys as possible candidates for use in the DSI 
prototype. The information will be organized according to product type. A summary 
report of all product information will be maintained and will be available at all times. 

As components which may have a significant impact on the DSI project are identified by 
GHG, the entry which goes in the summary report will be distributed to the members of the 
DSI team who may have a need for the component 

3. 1.3.4 Status and Lessons Learned 

On the first of each month, a status and lessons learned report will be distributed to all DSI 
team members. This report will identify the market areas that have been surveyed, the new 
products and components that have been reviewed, any new information regarding 
acquisition procedures, all product summary information that has been distributed to DSI 
team members during the previous month, and any other information related to component 
acquisition. 

3. 1.3.5 Restrictions, Turnaround Time, and Report Formats 

There shall be no access restrictions on any of the reports generated by GHG in accord 
with this component acquisition plan. Copies of all reports and information will be 
maintained at GHG for the duration of the contract period during which this acquisition 
plan is used. 

All reports generated by GHG under this plan will be made available within 1 working day. 
While verbal requests for reports will be sufficient in most cases, die 1 day turn around can 
only be guaranteed when written notice is given. Requested reports may be picked up at 
GHG or delivered by GHG to the appropriate site. Arrangements for delivery shall be 
made at the time of the request Repents will be available in hardcopy, W ordP erfect, and 
Microsoft Word f ormat s. WordPerfect an d Micros oft Word versions will be available on 
5.25" 360k or 1.2M floppy diskettes. Unless otherwise requested, reports will be 
delivered as hardcopy. 

3.2 Work Breakdown Structure (WBS) 

TBD 

3.2.1 Activity Definition 


TBD 

3.2.2 Cost Account Definition 
TBD 

3.3 Resource Estimation and Allocation to WBS 
TBD 


3.3.1 Schedules 


TBD 
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3.3.2 Funds and Budgets 
TBD 

3.3.3 Organization 
TBD 

3.3.4 Equipment 

GHG currently has the majority of the equipment which has been identified as necessary 
for the support of all functions to be performed for component acquisition throughout the 
life-cycle of the DSI prototype. 

The equipment which has been identified includes an IBM AT-class machine or compatible, 
WordPerfect and Microsoft Word word processors, laser printer output, and a photocopy 
machine. 

The equipment which GHG does not have is WordPerfect. This item shall be purchased 
by GHG under the contract for Phase 1 of the DSI prototype. 

All property management of the above equipment will be done by GHG Carp. 

3.3.5 Materials, Facilities, and Other Resources 

All materials, facilities, and other resources which have currently been identified as 
necessary to support the functions to be performed by GHG in accord with this component 
acquisition plan will be supplied by GHG. These items include, but are not limited to, 
office space, desks, paper, phones, postage, and other normal office supplies. GHG shall 
be responsible for the operating costs for the above items. 

3.3.6 Management Reserves 
TBD 

3.4 Work Authorization 

The following is a description of the work authorization process in terms of the actions 
required to initiate component acquisition or report generation. 

3.4.1 Component Acquisition 

After the need for a component has been recognized, GHG must be informed of the need 
so that the process of component acquisition can begin. While in some instances a verbal 
request may be sufficient, a written request is the only binding authorization for component 
acquisition. 

The request should include in as much detail, the nature of the component desired and the 
need it is to fill, possible candidates which may have already been identified by the 
requestor, unacceptable candidates accompanied by a rationale for each rejection, a 
schedule for the acquisition, a cost ceiling, and any other information which may help to 
identify candidates, reject inappropriate components, and expedite the component 
acquisition. 


3.4.2 Report Generation 


To initiate the generation of any report listed in section 3.1.3, a request must be made to 
GHG that includes a description or title of the report desired. Unless otherwise requested, 
the latest version of the report will be delivered in accord with section 3. 1.3.5. 

As with the initiation of the acquisition process, a verbal request may be sufficient, but a 
written request is the only binding request 


4.0 PURPOSE AND DESCRIPTION OF THE DSI PROTOTYPE 

Please refer to the Concept Document for the DSI Prototype. 


5.0 PROCUREMENT ACTIVITIES PLANNING 

This section describes the procurement activities and events conducted by the acquirer and 
identifies who will be responsible, where the activity will be performed, and when the 
activities will occur for each planned procurement 

5.1 Procurement Package Preparation 

The justification for acquisition of a compo nent mus t be described in relation to existing 
resources and the alternatives considered. 


5.1.1 Exi sting Resources 

The following is a list and a description of resources currently available for the DSI 
prototype development 

5.1. 1.1 Personnel 

UHCL - Dr. Charles W. McKay, Pat Rogers, Paul Brown, Karen Gunter 
Ford - Carl Lanham, Gary Cridland, Helen Watson, Joe Lozar 

GHG - Lionel Hanley, Gary O’Neal 


5.1. 1.1 Hardware and Associated Software 

Harris HCX-9 (Unix bsd4.2 based computer) - - 

The Harris is to be the main host machine. It is on this machine that most software 
development will take place, and all configuration management will be done. 
Software currently available on the Harris inc ludes: ^ 

- HAPSE (Harris Ada Programming Support 
Environment) 

- Oracle relational database management system 

- VI and EMACS text editors .. , ... 

- Ford RSL (Reusable Software Library) 


It is suggested that a configuration management tool such as CCC be purchased for 
the Harris. 


Apollo 3500 (two available) 

These machines are currently on lone to the University of Houston Clear Lake by 
Apollo. It is not clear how long these resources will be available. It is therefore 
suggested that the DSI prototype development avoid any dependence on these 
resources. This is not, however, to say that the Apollo's should not be used. 
Software on the Apollo's includes: 

- TAGS design and requirements analysis tool from Teledyne 

Brown Engineering 

- VADS (Verdix Ada Development System) 

It is hoped that DSSE (a configuration management tool from Apollo) will become 
available shortly. 


Sun Workstations 

Sun workstations are available at both GHG Corp. and at Ford Aerospace. Both 
have Ada compilers available. The use of these machines should be considered 
during the DSI prototype development 


IBM AT-class machines 

AT-class are available at all DSI prototype development sites. These machines will 
be useful for editing and document production. All documentation for the DSI 
prototype development should be available on this machine in WordPerfect form. 
In addition, AdaGen (an E/R modelling tool is available on this platform. 


MAC IIx 

A MAC IIx is soon to arrive at the university. This machine may serve well as a 
document generator. In addition, RDD-100 from Ascent Logic Corporation (a 
requirements analysis program) will be available soon after the MAC IIx arrives. 


5.1. 1.3 Other Software 

A variety of reusable Ada software components is available for use during the DSI 
prototype development. These include, but are not limited to the GRACE components, the 
Booch components, the CAMP (Common Ada Missile Packages) components, Ada X 
Windows Binding, Ada GKS binding, and a large number of other components available 
in the public domain. A more detailed list will be available during the next phase of the 
project 

5.1.2 Suggested Resources 

The following is a list and a description of resources which have been identified as needed 
or nice to have for the DSI prototype development. 


An Object Management System (OMS)would be nice for underlying object support. 
OMS's to consider include, but are not limited to Gaia, SLCSE, GEMS tone, Probe, and 
OMS9. 

An E/R modelling tool would be useful for a variety of the prototype efforts. As noted 
above, a copy AdaGen is currently available on AT-class machines. In addition, 
Excelerator is available at GHG and via the SSE. 

Library Management tools would be nice to organize libraries of components used in the 
DSI prototype development, the Ford RSL is available on the Harris. An RSL is also 
available from Barrios and Unisys. In addition, some of the previously mentioned OMS's 
have built in library management facilities. 

A "Black Box" test generator would be helpful. Such tools are available from Nokia and in 
the SLCSE environment from General Research. 

High speed dial-up modem facilities would be very nice to have at all DSI prototype 
development sites. It would be necessary for the university to install additional phone lines 
and for the university, Ford Aerospace and GHG to acquire high speed modems. 

Systems administration and operation is needed for all of the computer resources at the 
university. Such personnel would perform daily maintenance and operation of the 
machines such as backups, account creation, installation of software, etc. 

5.2 Proposal Evaluation 

The evaluation and selection of a software or hardware component will be done on a 
component by component basis. The entire DSI team should be made aware of any 
component needs so that any interested or informed person may be involved with the 
evaluation and selection of said component 

When the need for a component is recognized, the staff at GHG will be responsible for 
obtaining information on products which may satisfy the need. This information is to 
include, but not limited to, specifications, pricing, and availability. An initial evaluation of 
the candidate components will be made by GHG and these findings along: with all of the 
product information will be presented to the DSI prototype team and a decision on the 
acquisition will be made. 

The standards, practices, and methods employed in the component evaluation will be 
determined on a component by component basis. 

5.3 Contract Negotiation 

All final purchases and contract negotiations will be made by the appropriate purchasing 
department Prior to the actual purchase, all contract negotiations will be handled on a 
component by component basis during candidate evaluation and selection proceedings. 

Considerations which govern contract negotiations include, but are not limited to, cost and 
schedule adjustments, product adjustments, access rights, licence agreements, non- 
disclosure agreements, etc. 

5.4 Procurement Risks _ 



The largest and most obvious procurement risk is the amount of time necessary for the 
purchasing department to act on any purchase request 

At the university any major purchase (over $1000) must go out for written bids according 
to Texas State Law. In addition to the time taken by the university to initiate such a bid, the 
bid itself is open for 30 days. This is often followed by a delay of several weeks for the 
vendor to make delivery. 

One of the best ways to avoid delays in the purchasing department is to make no mistakes 
in the purchase request and to give them as much information as possible about the 
justification for the purchase. A little extra time spent on the paper work can save days or 
weeks on the delivery. 


6.0 ACQUISITION REQUIREMENTS 

6.1 Applicable Standards 

The nature of the DSI prototype development defies the definition of standards to be 
followed during the acquisition of components. The emphasis must be placed on achieving 
the desired level of functionality within the given time schedule. If a standard is available 
for a particular type of component, then the existence of the standard should be taken into 
consideration during product evaluation. 

If any standards are applied during the evaluation and selection of candidate components, 
they shall be recorded as part of the evaluation and selection criteria. 

6.2 Business Practices, Resources, and Organizational Requirements 

All requirements for the component provider's business practices, methods, reporting, 
metrics, etc., are set by the appropriate purchasing department in accord with the company 
or state requirements. In addition, any applicable NASA standards or requirements must 
also be recognized and satisfied. 

Requirements being placed on the provider with respect to product support, upgrades, 
adherence to standards, etc. are to be decided on a component by component basis during 
candidate evaluation and selection. 

If such requirements are made, they are to be recorded as part of the evaluation and 
selection criteria. 

6.3 Engineering and Integration Requirements 

Engineering an Integration requirements placed on the component provider will be decided 
on a component by component basis during candidate evaluation and selection. Such 
requirements may include, but are not limited to, use of specific tools or environments, use 
of specific programming languages, use of specific hardware, the "genericness" or 
reusability of the component, and special security or safety considerations. 

If such requirements are made, they are to be recorded as part of the evaluation and 
selection criteria. 


6.4 Risk Management Requirements 


The Risk Management requirements placed on the component provider will be decided on a 
component by component basis during candidate evaluation and selection. If the acquirer is 
especially concerned and wants to specifically address areas of risk, this must be taken into 
consideration during candidate evaluation and selection. 

If such requirements are made, they are to be recorded as part of the evaluation and 
selection criteria. 

6.5 Configuration Management Requirements 

Each component acquired for use in the DSI prototype will be subject to the configuration 
management policies defined in the configuration management plan. GHG will be 
responsible for insuring that all acquired components is properly placed under 
configuration control. Refer to the Configuration Management Plan of the Management 
Plan document for more detailed information. 

6.6 Classification and Assurance Requirements 

The Classification and Assurance requirements placed on the component provider will be 
decided on a component by component basis. If such requirements are made, they are to 
be recorded as part of the evaluation and selection criteria. 

6.7 Delivery Requirements 

Delivery Requirements placed on the component provider will be decided on a component 
by component basis within the guidelines established by the purchasing department 
handling the purchase. 

If any special delivery requirements such as installation support, conversion of data, 
acceptance procedures, or training provisions are imposed on the provider, they are to be 
recorded as part of the evaluation and selection criteria. 


6.8 Sustaining Engineering Support Requirements 

Sustaining Engineering Support requirements placed on the component provider will be 
decided on a component by component basis. Such requirements may include, but are not 
limited to, technical assistance, upgrades of the product, product assurance including 
regression testing and recertification. 

If such requirements are made, they are to be recorded as part of the evaluation and 
selection criteria. 


7.0 ACQUISITION ACTIVITIES PLANNING 

7.1 Acquis ition A ctivities 

The activities performed during component acquisition will be monitored and recorded by 
GHG. As such, GHG will be involved with all evaluations, selections, and negotiations 
which have an impact on component acquisition. In support of these activities, GHG shall 
provide as much insight into the evaluation as possible, including the identification of 
applicable standards if they exist In addition, GHG will record the discussions for 
inclusion in acquisition reports. 


GHG will work as closely as possible with the team members, their associated purchasing 
department, and the provider organization to insure that the component is available as 
quickly as possible. If the component is not delivered in satisfactory condition, or does not 
satisfy the need as described in the specification of the component, GHG will record the 
discrepancies and insure that the problem is corrected as quickly as possible. 

GHG shall collect metrics and all other information concerning the component acquisition. 

GHG shall insure that the component is properly placed under configuration management 
as defined in the Configuration Management Plan. Refer to the Configuration Management 
Plan for further description of the configuration management activities. 

Within one week of the time the component is delivered, GHG shall review the acceptance 
testing of the component with the acquirer. The information obtained in this review will be 
placed in the final component acquisition report. 


8.0 ABBREVIATIONS AND ACRONYMS 

9.0 GLOSSARY 

10.0 NOTES 

11.0 


APPENDICES 






